Device independent I/O is a well established concept in standard data communication and file I/O. Standard file I/O interfaces and communications protocols protect application programs from expensive source level changes due to changes in I/O device hardware and I/O device driver software. However, the past approaches have only been applicable to situations where the underlying data is the same from one I/O device to the next. For example, regardless of the different methods of physically storing and communicating files from the storage medium through the I/O device, a file is ultimately rendered as a stream of bytes to the application program. In contrast, there is another class of data I/O where the fundamental nature of the data changes depending on the I/O device from which the data is obtained. Digital images are an example of such a class of data I/O. One I/O device (a digital camera) may provide a binary image where each pixel is represented by a single bit. Another camera may capture a grey level image where each pixel is represented by a byte. An image from a color camera has three one byte values for the primary colors for each pixel. Additionally, manufacturers of these image I/O devices follow many different communications standards for I/O with the application program, such as pseudo file I/O, IEEE-488, and RS232. However, regardless of the structure of the data or the means of physical I/O, there are many operations which are semantically unaffected by the differences in the source or nature of the data. Several examples of such operations are "capture" an image, "display" an image, and "measure a feature" in an image. Another example of the class of data I/O that changes with the physical devices is data obtained from or output to motion control devices used in manufacturing automation or robotics.
For the class of data I/O where the fundamental nature of the data changes depending on the I/O device from which the data is obtained (i.e., device specific data), device independent I/O had not previously been accomplished. Application programs that input or output device specific data had to use special I/O devices installed on adapter cards which were interfaced to the computer channel. These special devices required application programs to have knowledge of I/O device specific information when inputting, processing, and outputting device specific data. In the past, this information had to be bound to the application program when it was compiled. Moreover, the application program had to be designed around this information. In order to support a new I/O device, the application program developer had to redesign the application program to accommodate the new information and then compile the new version of the application program.
As should be apparent from the foregoing discussion, inputting device specific data to, or outputting device specific data from, an application program using a new I/O device could be extremely time consuming and expensive. Typically, the application program developer had to redesign virtually the entire application program. This could be true even if there were only minor differences between the original I/O device and the new I/O device. Thus, as the size and complexity of the application program increased, the time and expense of redesigning the application program increased. Therefore, a need existed to reduce the time and expense of supporting a new I/O device in an application program, preferably by designing the application program to be independent of the I/O device and binding the I/O device specific information to the application program at runtime instead of when it is compiled.